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Introduction 


Purpose 

This  report  documents  the  F2025B  Force  Design  Analytic  Model  research  conducted  by  TRAC- 
MTRY  and  the  Naval  Postgraduate  School.  Our  research  develops  a  methodology  for  conducting 
quick-turn  force  design  given  a  mission  and  constraints;  it  helps  us  to  more  fully  understand  the  trade 
space  between  different  force  designs.  We  describe  a  data  development  methodology  that 
characterizes  the  data  required  to  construct  a  force  design  model  using  our  approach.  We  formulate  a 
mixed  integer  program  optimization  model  and  provide  an  implementation  using  GAMS  and  CPLEX. 
Finally,  we  analyze  a  resultant  force  design  from  a  model  constructed  using  this  methodology  in  a 
case  study. 

This  document  is  organized  into  two  sections.  In  the  Methodology  section,  we  provide  an  overview  of 
the  methodology  used  to  construct  force  design  models.  The  Summary  section  provides  a  summary  of 
our  findings. 

Background 

By  2025,  a  leaner,  smarter,  more  lethal,  and  flexible  Army  must  operate  differently,  enable  forces 
differently,  and  organize  differently  to  maintain  overmatch,  capable  of  responding  to  a  myriad  of 
threats  to  our  nation’s  national  interests,  and  to  set  the  conditions  for  fundamental  long-term  change. 
To  determine  the  optimal  design  for  the  Army  of  the  future,  the  Force  2025  and  beyond  effort  consists 
of  activities  along  three  primary  lines  of  effort:  force  employment;  science  and  technology  and  human 
performance  optimization;  and  force  design.  F2025B  seeks  a  structure  enabled  and  optimally 
organized  to  conduct  expeditionary  operations  and  fully  capable  of  Globally  Integrated  Operations 
while  ensuring  overmatch. 

TRADOC,  and  by  extension,  TRADOC  Analysis  Center  (TRAC),  conducts  analysis  to  support  force 
design  decisions,  including  operational  effectiveness  analysis.  Given  the  environment  that  future 
forces  will  need  to  operate  in,  TRAC  requires  analytic  capabilities  to  describe  an  enabled  and 
optimally  organized  F2025B. 

To  that  end,  we  seek  to  create  a  model  that  assists  decision  makers  in  exploring  design  options  in  the 
context  of  Army  operations.  The  intent  of  this  research  is  to  describe  and  evaluate  current 
organizational  designs  in  terms  of  Force  Employment  and  Force  Design  using  the  model  to  offer 
recommendations  and  analysis  that  could  improve  the  effectiveness  of  the  force  as  it  transitions  to 
F2025B.  The  end  result  is  a  force  design  model  capable  of  providing  insights  into  organization 
impacts  of  potential  changes  from  the  Wargaming  and  Experimentation  Season. 

From  this  central  motivation,  a  methodology  is  developed  to  illuminate  the  current  organizational 
design  structure  to  better  understand  how  the  network  of  BCTs  and  enablers  function  in  today’s  steady 
state  environment.  This  effort  will  enable  a  level  analysis  based  on  structural  groups  within  the  current 
organizations  that  possess  a  level  of  competence,  capability  and  capacity  to  execute  missions  and 
provide  support.  The  idea  is  to  align  units  with  inherent  capabilities  to  tasks  described  by  Army 
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doctrine,  then  map  those  tasks  to  defined,  scenario-driven  missions.  This  follows  the  ends-ways- 
means  approach  to  modeling  a  force  for  carrying  out  a  specified  operation. 

One  area  of  force  design  analysis  that  this  research  may  particularly  benefit  are  so-called  enabler 
organizations.  These  organizations  include  logistics  and  protection  units,  among  others,  that  provide 
services  to  main  warfighting  organizations,  such  as  Divisions  and  BCTs,  to  allow  decisive  operations. 

Project  Problem  Statement  and  Objectives 

Research  a  methodology  for  developing  a  strategic  level  visualization  tool  for  force  design  in 
order  to  more  fully  understand  the  Force  2025  and  Beyond  (F2025B)  trade  space.  Our  objectives 
are  to: 

1)  Use  Mixed  Integer  Program  optimization  to  better  understand  and  visualize  the  structural 
relationships  and  interactions  of  Force  Employment  and  Force  Design  of  the  current 
structure  of  Army  BCTs  and  enablers. 

2)  Develop  a  proof-of-concept  Mixed  Integer  Program  optimization  model  based  on  the 
ends-ways-means  strategic  construct  that  informs  force  design  for  F2025B  from  strategic 
to  tactical  fidelity  given  a  set  of  strategic  missions. 

3)  Demonstrate  use  of  the  model  for  quick  turn  force  shaping  analysis  for  enabler  units  in 
one  enabler  area:  Air  and  Missile  Defense;  within  one  phase  of  Army  operations:  Phase 
II:  Seize  the  Initiative. 

Constraints,  Limitations,  and  Assumptions 

Constraints  limit  the  project  team’s  options  to  conduct  the  study.  For  this  research,  we  identify 
the  following  constraints: 

•  Complete  the  project  no  later  than  March,  2017.  We  are  able  within  these  constraints  to 
provide  only  an  initial  foray  into  this  methodology. 

Limitations  are  a  project  team’s  inabilities  to  investigate  issues  within  the  sponsor’s  bounds.  In 
conducting  this  research  we  work  within  the  following  limitations: 

•  We  limit  the  investigation  to  focus  on  enabling  units,  rather  than  primary  warfighting 
units,  as  there  has  been  very  little  work  in  the  area  of  modeling  force  design  of  these 
types  of  units.  Specifically,  we  limit  ourselves  to  only  the  Air  and  Missile  Defense 
(AMD)  units  and  missions. 

•  Our  scenario  uses  only  Phase  II:  Seize  the  Initiative  mission  sets. 

Assumptions  are  research-specific  statements  that  are  taken  as  true  in  the  absence  of  facts.  For 
this  project,  the  team  identified  the  following  assumptions: 

•  Our  use  cases  would  serve  as  adequate  proof  of  principle  to  demonstrate  the  power  of  our 
force  design  modeling  methodology. 
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Methodology 


Overview 

Army  force  designs  and  force  structures  are  currently  developed  as  a  part  of  the  Army  Force 
Management  process.  Concepts  are  developed,  tested  and  implemented  into  doctrine  within  the 
various  Centers  of  Excellence  (COE)  for  each  Army  domain  of  warfighting.  Force  structure 
decisions  are  taken  as  a  part  of  the  Total  Army  Analysis  process,  which  is  underpinned  by 
combat  modeling  and  subject  matter  expert  elicitation  analysis.  TRAC  conducts  analysis  of 
different  force  designs  and  their  effects  on  the  larger  Army,  such  as  the  Army  End  Strength 
Analysis  study  (Pippin,  Pace,  Schemm,  Cunningham,  &  Castleberg,  2014),  the  BCT  Design 
Options  and  Other  Force  Structure  Trades  study  (Younger,  et  al.,  2015),  or  the  Force  Design/ 
Force  Mix:  Building  the  Best  Army  Possible  with  Reduced  End-Strength  study  (Dabkowski, 
Pippin,  Twohig,  Beck,  &  House,  201 1). 

We  propose  a  method  which  develops  force  designs  from  fundamental  constructs  that  are  linked 
through  tasks  and  capabilities  to  mission.  Our  methodology  first  defines  a  mission  set  associated 
with  mission  essential  tasks  quantified  through  mission  attributes  in  a  functional  hierarchy.  Our 
model  matches  units,  defined  at  a  fundamental  level,  using  capabilities  of  the  units  quantified 
through  the  same  mission  attributes  and  tasks,  to  specific  tasks  that  complete  the  given  mission. 
These  mission  sets  are  defined  at  the  operational  level  down  to  tactical,  collective  mission 
essential  tasks.  Figure  1  is  a  depiction  of  the  core  ideas  of  our  force  design  model. 


Wargame/SME  methodology 


F2025B  Analytic  model 


Basic  Unit  (Organization)  List 

-  Standardized  METL 

-  Task  Measures 

-  Availability  by  Unit 

-  Availability  constraints 


F2025B  Analytic  model  output. 


-  Forces  Required 

-  Capabilities  Required. 

-  Level  of  mission  completion 
achieved. 


Figure  1 :  Description  of  Force  Design  Model 


Figure  2  shows  an  overview  of  our  methodology.  In  step  1,  literature  review,  we  conduct  the 
standard  literature  review  and  scope  the  particular  force  design  problem.  From  the  literature 
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review,  some  main  outputs  are  potential  data  sources  and  constraints  on  force  design  solutions 
for  our  particular  enabler  unit  and  mission  area. 

Model  Development  and  Data  Model  Design,  together  consist  of  four  tasks.  First,  the  Data 
Model  is  developed  using  the  data  sources  identified  in  step  1.  This  includes  developing  the  unit 
capability  data,  unit  availability  data,  and  scenario  specification.  We  use  a  combination  of  SME 
elicitation  techniques  and  online  data  sources  such  as  FMSweb,  (https://fmsweb.armv.mil),  and 
the  Army  Training  Network  (ATN)  (https://atn.army.mil).  There  are  many  SME  elicitation 
techniques  available  for  constructing  a  functional  hierarchy  model,  unit  capability  data,  and 
scenario  specification.  See  reports  by  Marks,  Smead,  &  Alt,  2013,  or  Teter,  2014  for  a  discussion 
of  some  common  SME  elicitation  techniques. 

Scenario  specification  must  consist  of  identifying  the  overall  objective  and  mission,  then 
specifying  sub-missions  that  must  be  accomplished  to  complete  that  objective.  To  fully  specify 
the  scenario,  we  must  create  a  map  of  those  missions  to  mission  essential  tasks  that  can  be 
conducted  by  specific  types  of  units. 

Scenario  specification  is  best  done  through  SME  elicitations  such  as  staff  training  exercises  or 
Wargaming.  Unit  data  can  be  found  on  FMSweb  databases  to  give  the  total  numbers  of  each  type 
of  unit  within  the  force  design  unit  and  mission  area  we  are  investigating.  Unit  availability  data 
can  be  taken  from  TPFDD  data  or  other  unit  readiness  data  sources.  Unit  capability  data  and 
functional  hierarchies,  including  task  completion  attributes  should  be  developed  using  SME 
elicitation. 

Next,  we  develop  the  model.  The  objective  function  is  developed  using  a  decision  analysis 
technique  formally  referred  to  as  multiple  attribute  decision  theory  (Raiffa  &  Keeney,  1976), 
also  known  by  the  name  popularized  by  Keeney  in  1972  (1994)  as  Value  Focused  Thinking 
(VFT).  The  functional  hierarchies  are  constructed  and  then  capability  attributes  for  the  associated 
units  are  assigned  to  lower  tiers  of  the  hierarchy.  Each  unit  type  is  evaluated  against  the 
capability  attributes  to  determine  a  quantity  which  we  refer  to  as  unit  mission  value.  Putting  it 
differently,  the  unit  mission  value  is  defined  by  the  functional  hierarchy  and  later  used  as  the 
objective  function  coefficient  for  the  decision  variable  corresponding  to  that  unit  type.  A  further 
discussion  of  what  a  functional  hierarchy  looks  like  and  what  we  mean  by  objective  coefficients 
is  presented  later  in  this  document.  The  final  task  in  the  model  development  is  running  the  model 
on  our  developed  data  set  and  extracting  the  analytic  results. 

Steps  3  and  4  in  our  process  is  to  conduct  an  operational  analysis  using  this  unit  mission  area 
specific  model  and  reporting  the  results. 

In  our  research,  we  apply  this  methodology  to  one  simplified  example  under  an  unclassified 
scenario  derived  from  a  TRAC  Standard  Scenario.  One  weakness  of  this  research  is  that  we  only 
show  how  we  developed  the  model  for  this  case  and  not  what  types  of  force  design  operational 
analyses  can  be  conducted  using  the  model. 
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Figure  2:  Project  Methodology  Overview 


Objective  Function  Methodology  and  Data  Model  Design 

There  are  essentially  four  phases  in  developing  the  data  required  for  the  Force  Design  model,  the 
first  two  of  which  should  execute  concurrently.  First,  we  develop  capability  and  doctrinal  tasks 
associated  with  particular  Army  units  to  be  included  in  a  force  design  analysis.  Second,  we 
develop  a  scenario,  or  set  of  scenarios,  within  which  analyses  of  various  force  designs  will  take 
place.  Third,  we  develop  value  models  associated  with  each  mission  required  in  the  analytic 
scenario(s).  Finally,  we  develop  capability  data  for  each  of  Army  unit  in  our  analysis  based  on 
the  attributes  being  measured  in  our  defined  value  models. 


Development  of  Unit  doctrinal,  standardized  Mission  Essential  Task  Lists  (METLs) 

Most  of  our  example  unit  level  data  originates  from  FSMweb  (https://fmsweb.army.mil),  from 
which  we  extract  unit  types  and  named  units  of  each  type  resident  in  the  current  total  force.  We 
use  the  Army  Training  Network  (ATN)  (https://atn.army.mil),  which  contains  the  Central  Army 
Registry,  to  obtain  all  approved  unit  task  lists  by  unit  type. 

It  is  important  to  note  here  that  we  make  a  distinction  between  unit  types  and  units  available. 
Each  unit  available  has  a  unit  type.  Each  unit  type  has  characteristics  that  give  it  capabilities  for 
completing  different  tasks,  as  described  in  our  unit  type  task  list,  which  is  initially  derived  from 
the  collective  tasks  lists  for  each  unit  type.  The  Army  develops  and  updates  these  unit  collective 
tasks  lists  regularly. 

A  SME  reduces  our  unit  type  task  lists  to  match  our  developed  scenarios  using  professional 
military  judgement.  A  SME  ensures  that  tasks  selected  for  the  METL  of  each  unit  type  are  those 
important  to  the  unit’s  core  capabilities.  Results  of  this  phase  are  a  set  of  METL's  for  each  unit 
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type.  These  METL’s  guide  development  of  the  mission  required  tasks  in  the  scenario  as  well  as 
guide  development  of  the  unit  capabilities  based  on  the  attributes  defined  during  the  value 
modeling  phase. 

Scenario  Development  for  Force  Design  Analysis 

We  conduct  scenario  development  based  on  TRAC  Standard  scenarios.  Scenario  development 
begins  with  specifying  the  overall  strategic  mission,  then  listing  required  tasks  in  time  and  space 
within  the  specific  force  design  unit  and  mission  area  being  analyzed.  These  sub-tasks,  we  call 
them  mission  tasks,  all  contribute  in  some  way  toward  the  central  objective  of  the  scenario’s 
strategic  mission.  For  our  model,  we  limit  consideration  of  these  mission  tasks  to  only  one 
mission  area  at  a  time,  such  as  AMD,  engineer,  or  logistics.  This  simplifies  the  problem  and 
begins  to  prevent  interdependencies  between  different  capabilities  from  causing  problems  in  our 
model. 

There  are  several  SME  elicitation  techniques  that  can  be  useful  for  providing  the  type  of 
information  needed  to  define  the  scenario  fully.  The  simplest  way  to  think  about  the  problem  of 
developing  a  scenario  is  as  a  problem  of  planning  an  operation.  A  focus  group  that  walks  SMEs 
from  the  mission  area  being  analyzed  through  the  planning  process  or  data  from  a  group  of 
SMEs  conducting  a  wargame  around  the  central  objectives  of  the  base  scenario  should  provide 
sufficient  information  to  develop  the  scenario.  The  initial  scenario  development  for  our 
methodology  requires  only  a  task  list  and  start  and  end  times  of  each  task.  Table  1  shows  the 
basic  data  needed  for  our  example  model  in  the  AMD  unit  and  mission  space. 


Table  1:  Example  of  data  required  in  the  Mission  Task  List 


Mission  ID 

Mission 

Start  Time 

End  Time 

0 

Unit  Idle 

0 

13 

1 

Employ  AMD  at  FOB  One 

1 

12 

2 

Employ  AMD  at  FOB  One 

1 

12 

3 

Employ  AMD  at  FOB  Two 

1 

12 

4 

Employ  AMD  at  FOB  Two 

1 

12 

5 

Employ  AMD  at  OBJ  Rockfish 

6 

10 

6 

Employ  AMD  at  OBJ  Flounder 

6 

10 

7 

Employ  AMD  at  OBJ  Swordfish 

2 

8 

8 

Employ  AMD  at  OBJ  Squid 

2 

8 

9 

Employ  AMD  at  OBJ  Shark 

6 

12 

Functional  Hierarchy  Development  and  Definition  of  Mission  Value 

Value  models  consist  of  basically  two  parts;  an  objective  (or  functional)  hierarchy  linking  the 
overall  objective  through  sub-objectives  (or  tasks)  to  attributes  (or  required  capabilities);  and  a 
set  of  value  functions  that  can  (arbitrarily)  provide  measures  for  capability  contribution  to  each 
attribute  in  the  functional  hierarchy  (Raiffa  &  Keeney,  1976).  Essentially  the  functional 
hierarchies  are  mappings  of  the  set  of  tasks  and  supporting  tasks  required  to  complete  a  given 
mission  task.  Each  mapping  is  constructed  using  SME  professional  military  judgement  input.  For 
our  force  design  model,  a  functional  hierarchy  must  be  mapped  to  the  level  of  unit  for  which  the 
analysis  is  taking  place.  For  example,  if  we  are  conducting  a  platoon  level  analysis  of  force 
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design,  we  must  ensure  that  our  tasks  are  “sized”  for  the  platoon  level.  We  would  not,  for 
instance,  assign  a  platoon  of  infantry  to  attack  an  objective  containing  a  division  of  enemy 
infantry. 

At  the  base  of  each  of  these  functional  hierarchies  exist  attributes,  or  measures  of  capability.  In 
our  model,  mission  completion  is  measured  using  these  attributes  tied  to  value  functions.  The 
value  functions  output  the  value  each  unit  brings  to  the  mission  based  on  their  capability.  Value 
functions  are  described  in  more  detail  in  the  next  section.  We  borrow  the  bulk  of  our  value  model 
methodology  from  multi  attribute  decision  theory  (Raiffa  &  Keeney,  1976). 

At  the  core,  these  value  models  coupled  with  the  scenario  missions  and  fed  by  the  Unit  capability 
data  define  the  objective  function  of  the  F2025B  Force  Design  model.  The  central  idea  is  to 
maximize  the  value  of  a  force  design's  contribution  to  mission  completion.  By  way  of  definition, 
the  “value”  of  a  force  design  only  has  any  meaning  compared  to  other  force  designs  developed 
within  the  same  solution  space.  The  objective  function,  then,  can  be  thought  of  as  the  sum  of  the 
amount  of  value  that  each  Unit  brings  in  a  particular  time  period  for  performing  a  particular  task. 

The  value  modeling  approach  is  somewhat  subjective  and  changes  between  different  mission 
areas.  The  analyst  should,  in  particular,  conduct  sensitivity  analysis  on  the  "size"  of  unit  tasks. 

An  example  objective  hierarchy  is: 


Table  2:  AMD  Functional  Hierarchy  Input  Data 


Node  Id 

Node  Name 

Node  Type  Node  Parent  Id 

Node  Parent  Name 

SubObj  Level 

1 

Employ  Air  and  Missile  Defense  (AMD) 

High  Level  Task 

NA 

NA 

1 

2 

Conduct  AMD  Engagements  (Shoot) 

Sub  Objective 

1 

Employ  Air  and  Missile  Defense  (AMD) 

2 

3 

Conduct  AMD  Sensor  Ops  (Sense) 

Sub  Objective 

1 

Employ  Air  and  Missile  Defense  (AMD) 

2 

4 

Max.  Altitude  (Engage) 

Attribute 

2 

Conduct  AMD  Engagements  (Shoot) 

3 

5 

Max  Threat  Speed 

Attribute 

2 

Conduct  AMD  Engagements  (Shoot) 

3 

6 

Proportion  of  Area  Covered  (Shoot) 

Attribute 

2 

Conduct  AMD  Engagements  (Shoot) 

3 

7 

Max.  Altitude  (Sense) 

Attribute 

3 

Conduct  AMD  Sensor  Ops  (Sense) 

3 

8 

Min.  Altitude  (Sense) 

Attribute 

3 

Conduct  AMD  Sensor  Ops  (Sense) 

3 

9 

Max  Threat  Speed 

Attribute 

3 

Conduct  AMD  Sensor  Ops  (Sense) 

3 

10 

Proportion  of  Area  Covered  (Sense) 

Attribute 

3 

Conduct  AMD  Sensor  Ops  (Sense) 

3 

Employ  Air  and 
Missile  Defense 
(AMD) 


Figure  3:  Diagram  of  the  AMD  Functional  Hierarchy 
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Figure  3  depicts  a  functional  hierarchy  for  our  proof  of  principle  mission  set.  These  functional 
hierarchies  are  carefully  developed  by  SME’s  in  the  unit  and  mission  area  being  analyzed  for 
each  task. 

There  will  be  a  different  value  model  for  each  mission/task  within  the  overall  scenario  strategic 
mission.  Some  may  have  similar  value  models  if  there  are  only  small  changes,  for  instance,  over 
time  or  location.  However,  even  in  the  cases  of  time  and  location,  there  may  be  differences  in  the 
value  model  used  for  a  particular  mission  objective  or  mission  task.  These  differences  may  be 
subtle,  but  should  be  considered.  In  our  formulation,  we  assume  constant  value  models  over  time 
and  location.  We  use  mission  weighting  in  the  objective  function  to  show  relative  importance  of 
a  mission  in  one  location  over  the  same  type  of  mission  in  a  different  location. 

We  attempt  to  keep  all  the  sub-objectives  and  attributes  additive.  That  is  to  say  that  they  are 
mutually  exclusive,  independent,  and  are  collectively  exhaustive  of  the  mission  space.  As  this  is 
a  model,  the  collectively  exhaustive  stipulation  can  be  somewhat  relaxed,  as  we  are  most 
interested  in  analyzing  those  factors  that  are  most  important  to  the  system  under  study,  rather 
than  all  of  them.  If  there  is  a  significant  correlation  between  sub-objectives,  than  an  assumption 
of  independence  may  not  be  appropriate.  Though,  most  of  the  time,  small  correlations  can  be 
ignored  as  they  are  not  impacting  the  mission  significantly.  Nonetheless,  this  is  something  that 
must  be  tested  for  with  sensitivity  analysis. 

Value  Functions 

Each  attribute  has  a  value  function  specified  with  it.  The  function  specifies  the  value  that  a 
certain  level  of  capability  gives  for  that  particular  attribute. 

Our  input  data  structure  of  our  AMD  example  is  shown  in  Table  3: 


Table  3:  AMD  Attribute  Value  Functions  Input  Data 


ID 

Attribute 

Min 

Max 

PlotType 

Rho 

Weight 

1 

Max  Altitude  Engage 

0 

50 

Increasing  Convex 

5 

0.142857143 

2 

Max  Threat  Speed 

0 

3600 

Increasing  Concave 

2500 

0.142857143 

3 

PercArea  Covered 

0 

1 

Increasing  Linear 

inf 

0.142857143 

4 

Max  Alt  Sense 

0 

50 

Increasing  Convex 

5 

0.142857143 

5 

Min  Alt  Sense 

0 

50 

Decreasing  Concave 

3 

0.142857143 

6 

Max  Threat  Speed  Sense 

0 

3600 

Increasing  Concave 

2500 

0.142857143 

7 

PercArea  Covered  Sense 

0 

1 

Increasing  Unear 

inf 

0.142857143 

This  set  of  value  functions  is  for  the  value  model  specific  to  the  "Employ  AMD  against  low 
altitude,  low  speed  threats"  mission  task.  It  is  easy  to  programmatically  construct  different 
functions  using  a  parameterization  scheme.  For  our  methodology,  we  use  several  different 
functions,  including  linear,  step-wise,  and  exponential  functions.  Yet,  there  are  many  shapes  that 
can  be  parameterized  for  programmatic  access.  In  the  data  of  Table  3,  we  use  an  exponential 
function  to  provide  our  value  function  shapes.  The  p  (Rho)  value  column  is  a  parameter  that 
describes  the  degree  of  curve.  For  example,  in  Figure  4,  the  shape  is  increasing,  left  to  right,  and 
convex  (Increasing  Convex  plot  type).  A  smaller  p  would  cause  a  steeper  initial  climb,  where  a 
p  —  0  creates  essentially  a  straight  line  (though  in  our  function  we  actually  do  not  use  p  for 
linear  functions). 
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As  is  shown  in  Table  3,  each  value  function  is  weighted.  The  total  value  provided  for  the 
functional  hierarchy  shown  in  Table  3  is  simply  the  weighted  sum  across  the  value  functions. 
This  total  value  for  one  mission  task  represented  by  a  functional  hierarchy  such  as  the  one  in 
Table  3  can  then  be  inserted  into  the  objective  function  as  a  coefficient  for  a  decision  variable  for 
a  single  unit  type  evaluated  by  these  value  functions. 

For  example,  the  function  for  the  low  altitude  threat  "Max  Altitude  of  Threat  (Engage)"  value 
function  is  shown  in  Figure  4.  The  value  of  a  particular  unit  is  calculated  by  inputting  the 
maximum  altitude  at  which  that  unit  can  engage  a  threat  and  outputting  the  value  of  using  that 
unit  to  accomplish  the  task  of  engaging  low  altitude  threats. 

Value  Plot  of  Max  Altitude  Engage 


Figure  4:  The  value  function  plot  for  the  "Max  Altitude  of  Threat  (Engage)"  attribute.  As  the  range  capability  of  the 

unit  increases,  it  provides  more  value  to  task  completion. 

Once  each  value  for  a  particular  unit  type  is  calculated,  they  are  summed,  with  the  pre¬ 
determined  weights.  Now  the  coefficient  for  the  decision  variable  in  the  objective  function  for 
whether  a  particular  unit  of  that  particular  type  performs  this  mission  task  is  equal  to  the  value 
output  by  this  value  model. 

A  wholly  different  value  function  may  be  required  for  a  different  task.  For  the  ADA  example, 
engaging  low  altitude  threats  and  engaging  high  altitudes  threats  may  be  two  different  tasks.  A 
unit  that  can  only  engage  low  altitude  threats  is  preferable  when  engaging  low  altitude  threats, 
and  therefore  should  obtain  a  higher  value  on  the  value  function,  than  a  unit  that  can  only  engage 
high  altitude  threats  when  engaging  low  altitude  threats.  And  vice  versa.  Additionally,  a  unit  that 
can  engage  throughout  the  range  of  threats  may  obtain  the  most  value.  Therefore,  there  needs  to 
be  a  different  value  function  for  each  of  the  tasks,  engage  low  altitude  threats  versus  engage  high 
altitude  threats. 

Keep  in  mind  that  in  our  example  we  define  attributes  such  as  "low  altitude"  or  "high  altitude", 
etc.,  in  a  quantitative  sense  to  ensure  specificity.  In  out  example,  we  define  low  altitude  as 
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between  0  and  5  kilometers  above  sea  level,  medium  altitude  as  between  5  and  12  kilometers, 
and  high  altitude  as  between  12  and  50  kilometers.  This  partitioning  of  a  variable  should  come 
from  unit  and  mission  area  knowledge  and  is  meant  to  help  make  planning  a  scenario  more 
intuitive.  If  this  variable  were  used  as  a  continuous  variable,  then  there  can  be  infinite  number  of 
tasks  involving  altitude  of  threat,  for  instance,  and  therefore  infinite  number  of  value  models, 
which  we  wish  to  avoid.  Our  interactive  R  Shiny  application  (shown  in  Figure  5)  allows  users  to 
change  value  functions,  using  .csv  file  input  of  the  same  data  as  in  Table  3.  A  copy  of  the  code  is 
available  upon  request.  (PLACE  A  LINK  TO  R  SHINY  APP  ON  SERVER) 


Figure  5:  R  Shiny  App  for  processing  value  function  data. 

Unit  Capability  Data  Development 

Just  like  in  the  Unit  METL  phase,  we  start  by  deciding  which  units  to  leave  in  the  model  and 
which  to  leave  out.  Then,  we  look  at  all  the  value  models  (which  by  this  point  should  be 
synonymous  with  mission  task  break  down  to  measurement  attribute)  and  find  all  the  unique 
attributes  that  require  some  data  describing  a  units  capability  to  complete  that  task.  For  example, 
if  the  attribute  is  the  maximum  altitude  of  threat  during  engagement,  than  a  necessary  quantity  to 
show  for  each  unit  type  is  the  maximum  altitude  of  threat  that  the  particular  unit  can  engage. 

Input  data  structure  for  unit  type  capabilities  for  our  AMD  example  is  shown  in  Table  4: 
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Table  4:  Capabilities  for  each  ADA  unit  type  within  each  attribute  category. 


Unit  Type 

Unit  Type  Sub- 

Unit  ID  Num 

Max.  Altitude 
(Engage) 

Max  Threat 
Speed 

Coverage  Area 
(Shoot) 

Max.  Altitude 
(Sense) 

Min.  Altitude 
(Sense) 

Max  Threat 
Speed 

Coverage  Area 
(Sense) 

ADA  Battery  (AVENGER)  IFPC  Bn 

1 

12 

900 

10 

12 

0 

2300 

10 

ADA  Battery  (AVENGER)  Comp  Bn 

2 

12 

900 

10 

12 

0 

2300 

10 

ADA  Battery  (AVENGER) 

3 

12 

900 

10 

12 

0 

2300 

10 

ADA  Battery  (AVENGER)  ABN 

4 

12 

900 

5 

12 

0 

2300 

5 

ADA  Battery  (Intercept) 

5 

5 

2300 

2 

5 

0 

2300 

2 

ADA  Battery  (JLENS)  (SEPARATE) 

6 

0 

0 

0 

25 

0 

2300 

100 

ADA  Battery  (PATRIOT)  1 

7 

12 

2300 

25 

12 

0 

2300 

25 

ADA  Battery  (PATRIOT)  2 

8 

12 

2300 

25 

12 

0 

2300 

25 

ADA  Battery  (THAAD)  (SEPARATE) 

9 

50 

3600 

100 

50 

12 

3600 

100 

Unit  capabilities  can  be  developed  from  many  open  sources,  but  if  necessary,  can  also  be 
developed  from  classified  numbers.  For  this  type  of  analysis,  we  must  certainly  balance  the  need 
for  accuracy  in  the  numbers  with  the  need  to  keep  the  analysis  accessible  and  flexible. 

Next  we  develop  a  list  of  all  available  units.  This  list  should  include  the  unit  type  and  its 
available  start  and  end  time  periods.  The  unit  availability  list  should  look  like  the  data  in  Table  6 
in  Appendix  B.  At  a  minimum,  the  data  must  have  a  unit  name,  unit  type,  a  unit  type 
identification  number,  and  start  and  end  times  for  availability. 

Calculating  the  Value  of  Mission  Task  Completion 

This  step  consists  of  inputting  all  the  data  developed  so  far,  including  value  models  and  unit  type 
lists,  and  calculating  the  value  of  each  unit  type  performing  each  mission.  To  do  this,  we  must 
further  specify  each  of  the  missions  or  tasks  in  the  scenario  mission  list  so  that  the  model 
understands  which  value  model  to  use  in  calculating  the  unit  type  value  added  by  performance  of 
this  mission. 

Fully  Specifying  the  Mission  Task  List 

We  take  the  scenario  mission  task  list  and  specify  the  type  of  tasks.  Care  must  be  taken  to  ensure 
that  the  tasks  in  the  mission  list  are  sized  generally  correctly  for  the  unit  types  under 
consideration.  In  some  cases  additional  tasks  may  need  to  be  added  or  subtracted  as  the  task  is 
more  fully  specified.  For  example,  in  the  ADA  example,  we  may  have  a  requirement  to  provide 
air  and  missile  defense  at  FOB  One.  There  will  be  both  low  altitude  threats  and  high  altitude 
threats.  However,  there  may  be  enough  threats  of  each  type  to  warrant  specifying  a  low  altitude 
task  and  a  high  altitude  task  so  that  the  model  will  assign  two  different  units.  The  same  could  be 
said  if  there  are  only  low  altitude  threats,  but  the  scenario  designer  knows  that  there  are  more 
than  enough  threats  to  keep  at  least  two  of  the  general  size  units,  in  this  case  battery  or  company 
level,  busy,  or  there  may  be  a  huge  area  to  cover  and  more  than  one  battery  sized  unit  (of  any 
type)  is  known  to  not  be  capable  of  covering  the  whole  area.  Then  we  should  specify  two  or 
more  low  altitude  engagement  tasks. 

Requirements  are  then  added  to  the  tasks  that  correspond  to  the  attributes  of  the  specific  value 
models  for  that  tasks.  If  a  value  model,  with  appropriate  value  functions,  was  not  created  for  that 
specific  task,  then  a  value  model  to  match  that  specific  task  must  be  created.  Any  additional 
attributes  then  must  be  considered  and  unit  type  capabilities  updated  to  include  unit  capabilities 
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for  the  new  attributes.  In  this  way,  the  data  development  process  can  be  iterative  as  the  analyst 
refines  the  model.  Table  7  in  Appendix  B  is  an  example  of  input  data  for  a  fully  specified 
scenario  mission  task.  The  necessary  data  for  mission  task  specification  includes  mission  name, 
start  and  end  time  periods,  and  a  measure  of  “how  much”  of  the  mission  is  required  along  the 
attributes  in  the  value  model  for  that  mission  task.  For  the  AMD  example,  each  mission  task  is 
defined  in  six  attributes.  Note  that  the  altitudes  and  speeds  for  the  AMD  example  are  specified  in 
three  different  ranges.  The  number  in  the  table  corresponds  to  the  range  required  to  complete  the 
given  mission  task. 

Calculating  Values  of  Units  Performing  each  Mission 

Next,  for  each  mission,  we  calculate  a  value,  using  the  value  model  for  that  mission,  for  each 
unit  type.  Sometimes  there  is  an  additional  function  that  maps  the  unit  capability  to  the  attribute. 
This  function  should  take  as  input  the  required  capability  specified  by  the  mission  or  task 
definition  and  the  capability  of  the  unit.  For  instance,  the  attribute  "Proportion  of  Area  Covered" 
entails  the  total  area  that  the  unit  is  capable  of  covering  divided  by  the  required  capability  to 
perform  the  task.  This  number  is  then  used  to  determine  the  value  that  the  unit  contributes  to 
completion  of  that  task. 

Table  8  Appendix  B  shows  output  in  a  matrix  of  unit  type  to  mission  value  (R  code  for 
calculating  this  matrix  is  available  upon  request),  where  unit  types  are  along  the  rows  and 
mission  tasks  are  along  the  columns.  The  numbers  in  Table  8  essentially  become  the  coefficients 
in  the  objective  function  of  our  MIP  optimization  formulation. 

Mixed  Integer  Program  Formulation 

The  primary  model  can  be  stated  as  a  mixed-integer  linear  programming  model.  Notation  and 
formulation  is  presented  here  in  the  Naval  Postgraduate  School  (NPS)  formal  style  (Brown  & 
Dell,  2007): 

Indicies 

m,  m '  missions  (also  referred  to  as  tasks)  and  the  associated  alias. 
u  units 

t  time  segments  (also  referred  to  as  periods). 

Derived  Sets 

UMTu  m  t  derived  set  of  all  units  u  that  may  be  assigned  mission  m  in  period  t. 

MTm  t  derived  set  of  all  missions  m  that  should  be  accomplished  in  period  t. 

Parameters  [units]: 

umvalueu  m  t  value  received  if  unit  u  is  assigned  to  mission  m  in  period  t.  The  “unit  mission 
value”  is  a  derived  parameter  determined  by  the  functional  hierarchy  model. 


12 


pen  small  data  specific  penalty  that  ensures  units  are  not  assigned  unnecessarily. 

Decision  Variables  [units]: 

Z  objective  function  value,  [unit  mission  value] 

Xu  m  t  binary  variable  with  value  1  if  unit  u  is  assigned  to  mission  m  in  period  t. 

Yu  m  t  binary  variable  with  value  1  if  unit  u  is  not  assigned  to  mission  m  in  period  t  after 

being  assigned  to  mission  m  the  previous  period  l-l . 

Objective : 

Maximize  V  umvalue X  m  -  V  pen  Y  .  (1) 

u,m,t  u,m,t  t  u,m,t  v  ' 

u,m,t\UMTu  m  t  u,m,t\UMTu  m  t 

Constraints : 

Z  =  l  Vra,(IMr„,  (2) 

u\UMTumJ 


Z  X„.„<1  v«,r 

(3) 

m\UMTumt 

Z  Vu,m,t\UMT-mJ 

(4) 

m'lm^m'n  UMTU 

Xu,,nJ->  +  Xu,m,t  ^  Yu,m,t  V  1  1  UMTu,m,< 

(5) 

xu,m,t  e(0^}  Vw,mT 

(6) 

yu,mj  e  {0,1}  \/u,m,t 

(7) 

Formulation  Discussion 

The  objective  function,  Equation  (1),  selects  those  unit  and  mission  pairings  that  maximizes  the 
total  value  over  all  time  periods  while  at  the  same  time  minimizes  the  unit  moves  between 
missions.  Equation  (2)  ensures  that  one  and  only  one  unit  will  be  assigned  to  all  missions  in  each 
time  period.  Equation  (3)  ensures  that  a  unit  will  not  be  tasked  to  more  than  one  mission  during 
each  time  period.  Equation  (4)  requires  that  a  unit  cannot  move  from  one  mission  to  another  in  a 
subsequent  time  period  immediately  following  the  last.  Equation  (5),  in  conjunction  with 
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Equation  (4),  ensures  that  a  unit  which  is  reassigned  to  another  mission  in  a  subsequent  period 
incurs  a  “unit  movement  and  setup”  penalty.  Equations  (6)  and  (7)  enforce  the  binary  constraints. 

This  formulation  is  customized  for  a  specific  data  set  defined  in  the  later  sections  of  this  paper. 
As  such  this  formulation  serves  as  a  frame  work  for  other  scenarios.  For  example,  Equation  (4) 
implies  that  one  period  is  required  between  mission  moves.  In  cases  where  more  than  one  period 
is  required  to  move  from  one  mission  to  another,  the  only  change  that  is  required  to  Equation  (4) 
is  the  appropriate  change  to  the  right  hand  side  of  equation  (4).  As  demonstrated,  precedence  is 
demonstrated  in  constraints  (4)  and  (5)  and  can  easily  be  scaled  to  other  scenarios  by  either  using 
the  same  constructs  or  adding  additional  constraints  as  necessary. 


Bringing  it  Together:  Solving  the  model 


Finally,  we  manipulate  the  data  into  an  objective  coefficient  vector  and  constraint  matrices  using 
a  series  of  scripts.  We  have  implemented  several  R  scripts  that  automate  this  and  produce  the 
necessary  files.  Once  we  have  the  data  calculated  in  the  correct  format,  we  use  solving  software 
to  solve  for  the  optimal  force  design.  Table  5  shows  the  raw  output  of  solving  using  GAMS  with 
the  CPLEX  solver  combined  with  the  unit  name  and  type  of  each  unit  the  model  chose  within 
each  time  period.  Our  methodology  can  be  used  with  any  popular  algebraic  modeling  and  solver 
software,  including  packages  such  as  pyomo  in  Python  or  IpSolve  in  R  using  the  lp_solve  solver 
software.  We  have  currently  implemented  it  in  GAMS/CPLEX. 


Table  5:  AMD  Example  GAMS  Solver  output. 


T1 

Mission  Unit 
Ml  U7 

M2  U53 

M3  U63 

M4  U2 


Value  |unitName  |unitType  |  Unit  Type  |  Avail  (T>=)  |  Not  Avail  (T>=)~| 


10  CCO,  1st  BATTALION,  1ST  AIR  DEFENSE  ARTILLERY  REGIMENT  ADA  Battery  (PATRIOT)  2  8  0  27 

9  D  BATT,  4TH  BATTALION,  3D  AIR  DEFENSE  ARTILLERY  REGIMENT  ADA  Battery  (PATRIOT)  2  8  1  28 

10  D  BATT,  3D  BATTALION,  4TH  AIR  DEFENSE  ARTILLERY  REGIMENT  ADA  Battery  (PATRIOT)  17  1  28 

9  B  CO,  4th  BATTALION,  5TH  AIR  DEFENSE  ARTILLERY  REGIMENT  ADA  Battery  (PATRIOT)  2  8  0  27 


T2 

Mission  Unit 
Ml  U7 

M2  U53 

M3  U63 

M4  U2 

M7  U24 

M8  U1 


Value  |  Unit  Name  |  Unit  Type  |  Unit  Type  |  Avail  (T>=)  |  Not  Avail  (T>=)  | 


10  C  CO,  1st  BATTALION,  1ST  AIR  DEFENSE  ARTILLERY  REGIMENT  ADA  Battery  (PATRIOT)  2  8  0  27 

9  D  BATT,  4TH  BATTALION,  3D  AIR  DEFENSE  ARTILLERY  REGIMENT  ADA  Battery  (PATRIOT)  2  8  1  28 

10  D  BATT,  3D  BATTALION,  4TH  AIR  DEFENSE  ARTILLERY  REGIMENT  ADA  Battery  (PATRIOT)  17  1  28 

9  B  CO,  4th  BATTALION,  5TH  AIR  DEFENSE  ARTILLERY  REGIMENT  ADA  Battery  (PATRIOT)  2  8  0  27 

9  D  BATT,  2D  BATTALION,  43D  AIR  DEFENSE  ARTILLERY  REGIMENT  ADA  Battery  (PATRIOT)  2  8  1  28 

9  A  CO,  4th  BATTALION,  5TH  AIR  DEFENSE  ARTILLERY  REGIMENT  ADA  Battery  (PATRIOT)  2  8  2  29 


T3 

Mission  Unit 
Ml  U7 

M2  U53 

M3  U63 

M4  U2 

M7  U24 

M8  U1 


Value 


Unit  Name 


|unitType|Avail  (T >=)  |Not  Avail  (T>=)~| 


|UnitType 


10  C  CO,  1st  BATTALION,  1ST  AIR  DEFENSE  ARTILLERY  REGIMENT 
9  D  BATT,  4TH  BATTALION,  3D  AIR  DEFENSE  ARTILLERY  REGIMENT 
10  D  BATT,  3D  BATTALION,  4TH  AIR  DEFENSE  ARTILLERY  REGIMENT 
9  B  CO,  4th  BATTALION,  5TH  AIR  DEFENSE  ARTILLERY  REGIMENT 
9  D  BATT,  2D  BATTALION,  43D  AIR  DEFENSE  ARTILLERY  REGIMENT 
9  A  CO,  4th  BATTALION,  5TH  AIR  DEFENSE  ARTILLERY  REGIMENT 


ADA  Battery  (PATRIOT)  2 

8 

0 

27 

ADA  Battery  (PATRIOT)  2 

8 

1 

28 

ADA  Battery  (PATRIOT)  1 

7 

1 

28 

ADA  Battery  (PATRIOT)  2 

8 

0 

27 

ADA  Battery  (PATRIOT)  2 

8 

1 

28 

ADA  Battery  (PATRIOT)  2 

8 

2 

29 
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T10 

Mission 

Unit 

Value 

| Unit  Name 

junitType  |unitType| 

Avail  (T>=) 

Not  Avail  (T>=) 

Ml 

U7 

10  C  CO,  1st  BATTALION,  1ST  AIR  DEFENSE  ARTILLERY  REGIMENT 

ADA  Battery  (PATRIOT)  2 

8 

0 

27 

M2 

U53 

9  D  BATT,  4TH  BATTALION,  3D  AIR  DEFENSE  ARTILLERY  REGIMENT  ADA  Battery  (PATRIOT)  2 

8 

1 

28 

M3 

U63 

10  D  BATT,  3D  BATTALION,  4TH  AIR  DEFENSE  ARTILLERY  REGIMENT  ADA  Battery  (PATRIOT)  1 

7 

1 

28 

M4 

U2 

9  B  CO,  4th  BATTALION,  5TH  AIR  DEFENSE  ARTILLERY  REGIMENT 

ADA  Battery  (PATRIOT)  2 

8 

0 

27 

M5 

U55 

9  BATTERY  B,  2D  AIR  DEFENSE  ARTILLERY  REGIMENT 

ADA  Battery  (THAAD)  (SEF 

9 

5 

32 

M6 

U54 

9  BATTERY  A,  2D  AIR  DEFENSE  ARTILLERY  REGIMENT 

ADA  Battery  (THAAD)  (SEF 

9 

1 

28 

M9 

Til 

U29 

9  BATTERY  D,  2D  AIR  DEFENSE  ARTILLERY  REGIMENT 

ADA  Battery  (THAAD)  (SEF 

9 

4 

31 

Mission 

Unit 

Value 

|unit  Name 

|unitType 

Unit  Type  |  Avail  (T>=) 

Not  Avail  (T>=) 

Ml 

U7 

10  C  CO,  1st  BATTALION,  1ST  AIR  DEFENSE  ARTILLERY  REGIMENT 

ADA  Battery  (PATRIOT)  2 

8 

0 

27 

M2 

U53 

9  D  BATT,  4TH  BATTALION,  3D  AIR  DEFENSE  ARTILLERY  REGIMENT  ADA  Battery  (PATRIOT)  2 

8 

1 

28 

M3 

U63 

10  D  BATT,  3D  BATTALION,  4TH  AIR  DEFENSE  ARTILLERY  REGIMENT  ADA  Battery  (PATRIOT)  1 

7 

1 

28 

M4 

U2 

9  B  CO,  4th  BATTALION,  5TH  AIR  DEFENSE  ARTILLERY  REGIMENT 

ADA  Battery  (PATRIOT)  2 

8 

0 

27 

M9 

T12 

U29 

9  BATTERY  D,  2D  AIR  DEFENSE  ARTILLERY  REGIMENT 

ADA  Battery  (THAAD)  (SEF 

9 

4 

31 

Mission 

Unit 

Value 

| Unit  Name 

|unitType  |UnitType| 

Avail  (T  >=)  |Not  Avail  (T>=) 

Ml 

U7 

10  C  CO,  1st  BATTALION,  1ST  AIR  DEFENSE  ARTILLERY  REGIMENT 

ADA  Battery  (PATRIOT)  2 

8 

0 

27 

M2 

U53 

9  D  BATT,  4TH  BATTALION,  3D  AIR  DEFENSE  ARTILLERY  REGIMENT  ADA  Battery  (PATRIOT)  2 

8 

1 

28 

M3 

U63 

10  D  BATT,  3D  BATTALION,  4TH  AIR  DEFENSE  ARTILLERY  REGIMENT  ADA  Battery  (PATRIOT)  1 

7 

1 

28 

M4 

U2 

9  B  CO,  4th  BATTALION,  5TH  AIR  DEFENSE  ARTILLERY  REGIMENT 

ADA  Battery  (PATRIOT)  2 

8 

0 

27 

M9 

U29 

9  BATTERY  D,  2D  AIR  DEFENSE  ARTILLERY  REGIMENT 

ADA  Battery  (THAAD)  (SEF 

9 

4 

31 

This  information  can  be  useful  to  planners  when  arranging  forces  against  missions  over  time.  It 
can  also  be  analyzed  to  gain  insights  about  the  types  of  units  that  are  most  cost  effective,  giving  a 
reasonable  amount  of  mission  success,  against  different  mission  types.  Also,  this  data  can  give  us 
insights  about  the  right  mix  of  units  at  every  echelon  that  provides  flexibility  and  robustness  to 
changes  in  mission. 
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Summary 


The  methodology  we  present  here  provides  a  way  to  think  about  how  to  design  our  Army  forces 
to  meet  mission  demands  in  terms  of  tasks  that  are  required  for  mission  completion.  We  show 
how  a  set  of  data  can  be  constructed  to  map  a  unit’s  capabilities  to  required  tasks  using  doctrinal 
tasks  and  missions. 

Our  research  represents  the  initial  work  in  using  this  type  of  methodology  to  construct  force 
design  models  using  a  mission-focused,  task-based,  capability  architecture.  We  demonstrate  our 
force  design  methodology  and  possible  insights  that  come  from  the  methodology.  However,  due 
to  time  and  resource  constraints,  we  have  not  finished  developing  a  full  trade-space  visualization 
tool.  Additionally,  many  improvements  can  be  made  with  future  research,  building  on  this  base 
methodology  to  develop  tools  for  increasing  the  effectiveness  of  this  methodology,  such  as  a 
web-based  tool  to  quickly  create  and  save  force  capability  data  and  value  models. 

One  major  result  of  our  research  is  the  discovery  that  each  enabler  unit  mission  set  requires  a 
construction  of  a  set  of  unique  value  models,  though  using  the  same  MIP  formulation.  Our 
research  also  concluded  that  initial  development  of  the  functional  hierarchies  and  value  functions 
is  difficult  and  time  consuming.  Future  research  can  explore  different  methods  for  overcoming 
these  limitations,  such  as  developing  libraries  of  these  models  for  each  unit  mission  area.  These 
libraries  can  be  made  readily  available  and  can  be  updated  periodically  as  tasks  and  missions 
change  over  time,  which  is  much  easier  than  initial  development. 

Further  work  is  needed,  but  this  methodology  provides  good  insights  and  may  well  prove  to  have 
much  more  accessible  results  at  shorter  timelines  than  many  existing  analytic  alternatives.  Our 
methodology  provides  a  clear,  objective  way  to  use  concrete  data  in  conjunction  with  well- 
reasoned  subjective  inputs  to  provide  insights  into  U.S.  Army  force  design. 
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Appendix  B  -  Tabular  Data  for  AMD  Proof  of  Principle 


Table  6:  Notional  unit  availability  data  for  ADA  units. 


Unit  Id 

UIC 

Unit  Name 

Unit  Type 

Unit  Type  ID 

Avail  (T  >=) 

Not  Avail  (T>=) 

1 

WA1AAA  - 1 

A  CO,  4th  BATTALION,  5TH  AIR  DEFENSE  ARTILLERY  REGIMENT 

ADA  Battery  (PATRIOT)  2 

8 

2 

2 

2 

WA1AAA  -  2 

B  CO,  4th  BATTALION,  5TH  AIR  DEFENSE  ARTILLERY  REGIMENT 

ADA  Battery  (PATRIOT)  2 

8 

0 

0 

3 

WA1AAA  -  3 

C  CO,  4th  BATTALION,  5TH  AIR  DEFENSE  ARTILLERY  REGIMENT 

ADA  Battery  (PATRIOT)  2 

8 

1 

1 

4 

WA1AAA  -  4 

D  CO,  4th  BATTALION,  5TH  AIR  DEFENSE  ARTILLERY  REGIMENT 

ADA  Battery  (PATRIOT)  2 

8 

0 

0 

5 

WAC2AA-1 

A  CO,  1st  BATTALION,  1ST  AIR  DEFENSE  ARTILLERY  REGIMENT 

ADA  Battery  (PATRIOT)  2 

8 

0 

0 

6 

WAC2AA-2 

B  CO,  1st  BATTALION,  1ST  AIR  DEFENSE  ARTILLERY  REGIMENT 

ADA  Battery  (PATRIOT)  2 

8 

0 

0 

7 

WAC2AA-3 

C  CO,  1st  BATTALION,  1ST  AIR  DEFENSE  ARTILLERY  REGIMENT 

ADA  Battery  (PATRIOT)  2 

8 

0 

0 

8 

WAC2AA-4 

D  CO,  1st  BATTALION,  1ST  AIR  DEFENSE  ARTILLERY  REGIMENT 

ADA  Battery  (PATRIOT)  2 

8 

0 

0 

9 

WAW0AA-1 

A  CO,  6th  BATTALION,  52D  AIR  DEFENSE  ARTILLERY  REGIMENT 

ADA  Battery  (PATRIOT)  1 

7 

5 

5 

10 

WAWOAA-2 

B  CO,  6th  BATTALION,  52D  AIR  DEFENSE  ARTILLERY  REGIMENT 

ADA  Battery  (PATRIOT)  1 

7 

0 

0 

11 

WAW0AA-3 

C  CO,  6th  BATTALION,  52D  AIR  DEFENSE  ARTILLERY  REGIMENT 

ADA  Battery  (PATRIOT)  1 

7 

0 

0 

12 

WAW0AA-4 

D  CO,  6th  BATTALION,  52D  AIR  DEFENSE  ARTILLERY  REGIMENT 

ADA  Battery  (PATRIOT)  1 

7 

2 

2 

13 

WAW0AA-5 

E  CO,  6th  BATTALION,  52D  AIR  DEFENSE  ARTILLERY  REGIMENT 

ADA  Battery  (AVENGER)  Comp  Bn 

2 

5 

5 

14 

WAWLAA-1 

A  BATT,  5th  BATTALION,  5TH  AIR  DEFENSE  ARTILLERY  REGIMENT 

ADA  Battery  (AVENGER)  IFPC  Bn 

1 

9 

9 

91 

WYJZAA-3 

C  BATT,  1ST  BATTALION,  188TH  AIR  DEFENSE  ARTILLERY  REGIMENT 

ADA  Battery  (AVENGER) 

3 

5 

5 

92 

WYKSAA-1 

A  BATT,  3D  BATTALION,  265TH  AIR  DEFENSE  ARTILLERY  REGIMENT 

ADA  Battery  (AVENGER) 

3 

5 

5 

93 

WYKSAA-2 

B  BATT,  3D  BATTALION,  265TH  AIR  DEFENSE  ARTILLERY  REGIMENT 

ADA  Battery  (AVENGER) 

3 

5 

5 

94 

WYKSAA-3 

C  BATT,  3D  BATTALION,  265TH  AIR  DEFENSE  ARTILLERY  REGIMENT 

ADA  Battery  (AVENGER) 

3 

5 

5 

95 

WYKVAA-1 

A  BATT,  1ST  BATTALION,  265TH  AIR  DEFENSE  ARTILLERY  REGIMENT 

ADA  Battery  (AVENGER) 

3 

5 

5 

96 

WYKVAA-2 

B  BATT,  1ST  BATTALION,  265TH  AIR  DEFENSE  ARTILLERY  REGIMENT 

ADA  Battery  (AVENGER) 

3 

10 

10 

97 

WYKVAA-3 

C  BATT,  1ST  BATTALION,  265TH  AIR  DEFENSE  ARTILLERY  REGIMENT 

ADA  Battery  (AVENGER) 

3 

2 

7 

Table  7:  Fully  specified  mission  list  including  required  capabilities  in  order  to  successfully  complete  each  mission 

task. 


Mission  ID 

Mission 

Start  Time 

End  Time 

Max.  Threat  Altitude  for 

Engagement 

Max.  Threat 

Speed 

Engagement 
Coverage  Area 

Threat  Altitude 

for  Sensing 

Max.  Threat 
Speed  for 
Sensing 

Sensor  Coverage 

Area 

1 

Employ  AMD  at  FOB  One 

1 

12 

1 

1 

25 

1 

1 

25 

2 

Employ  AMD  at  FOB  One 

1 

12 

2 

2 

25 

2 

2 

25 

3 

Employ  AMD  at  FOB  Two 

1 

12 

1 

1 

25 

1 

1 

25 

4 

Employ  AMD  at  FOB  Two 

1 

12 

2 

2 

25 

2 

2 

25 

5 

Employ  AMD  at  OBJ  Rockfish 

6 

10 

1 

2 

30 

1 

2 

30 

6 

Employ  AMD  at  OBJ  Flounder 

6 

10 

1 

2 

30 

1 

2 

30 

7 

Employ  AMD  at  OBJ  Swordfish 

2 

8 

1 

2 

15 

1 

2 

15 

8 

Employ  AMD  at  OBJ  Squid 

2 

8 

1 

2 

15 

1 

2 

15 

9 

Employ  AMD  at  OBJ  Shark 

6 

12 

1 

2 

30 

1 

2 

30 

Table  8:  Value  of  each  unit  type  conducting  each  of  the  9  example  AMD  mission  tasks. 


Unit  Type 

Employ  AMD 

at  FOB  One 

Employ  AMD 

at  FOB  One 

Employ  AMD 

at  FOB  Two 

Employ  AMD 

at  FOB  Two 

Employ  AMD 
at  OBJ 

Rockfish 

Employ  AMD 

at  OBJ 

Flounder 

Employ  AMD 

at  OBJ 

Swordfish 

Employ  AMD 
at  OBJ  Squid 

Employ  AMD 
at  OBJ  Shark 

ADA  Battery  (AVENGER)  IFPC  Bn 

8.29 

6.32 

8.29 

6.32 

6.12 

6.12 

7.08 

7.08 

6.12 

ADA  Battery  (AVENGER)  Comp  Bn 

8.29 

6.32 

8.29 

6.32 

6.12 

6.12 

7.08 

7.08 

6.12 

ADA  Battery  (AVENGER) 

8.29 

6.32 

8.29 

6.32 

6.12 

6.12 

7.08 

7.08 

6.12 

ADA  Battery  (AVENGER)  ABN 

7.71 

5.74 

7.71 

5.74 

5.65 

5.65 

6.12 

6.12 

5.65 

ADA  Battery  (Intercept) 

7.37 

3.23 

7.37 

3.23 

6.05 

6.05 

6.24 

6.24 

6.05 

ADA  Battery  (JLENS)  (SEPARATE) 

5.71 

5.07 

5.71 

5.07 

5.07 

5.07 

5.07 

5.07 

5.07 

ADA  Battery  (PATRIOT)  1 

10.00 

8.72 

10.00 

8.72 

8.24 

8.24 

8.72 

8.72 

8.24 

ADA  Battery  (PATRIOT)  2 

10.00 

8.72 

10.00 

8.72 

8.24 

8.24 

8.72 

8.72 

8.24 

ADA  Battery  (THAAD)  (SEPARATE) 

8.57 

8.57 

8.57 

8.57 

8.57 

8.57 

8.57 

8.57 

8.57 
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Appendix  C  -  Acronyms 


AMD 

Air  and  Missile  Defense 

ADA 

Air  Defense  Artillery 

ATN 

Army  Training  Network 

BCT 

Brigade  Combat  Team 

CPLEX 

Simplex  Method  Implemented  in  C 

COE 

Center  of  Excellence 

F2025B 

Force  2025  and  Beyond 

GAMS 

General  Algebraic  Modeling  System 

MDMP 

Military  Decision  Making  Process 

METL 

Mission  Essential  Task  List 

MIP 

Mixed  Integer  Program 

NPS 

Naval  Postgraduate  School 

SME 

Subject  Matter  Expert 

TDA 

Table  of  Distribution  and  Allowance 

TPFDD 

Time  Phased  Force  Deployment  Data 

TOE 

Table  of  Organization  and  Equipment 

TRAC 

TRADOC  Analysis  Center 

TRADOC 

Training  and  Doctrine  Command 

TRAC-MTRY 

TRADOC  Analysis  Center-  Monterey 

VBA 

Visual  Basic  for  Applications 
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